In the context of communication networks, such as telecommunication networks, network operators often want to define and enforce a set of rules in the network. A set of rules constitutes policies. A policy framework for managing and enforcing these policies usually includes three elements, or functions: a policy repository for storing the policy rules which may be user-specific, a policy decision element, function or point, and a policy enforcement element, function or point. The purposes of a policy framework include controlling subscriber access to the networks and services.
A policy framework notably addresses the decisions as to whether the subscriber is entitled, or authorized, to enjoy a service that may be invoked by an application being executed on a user terminal, and whether the network can provide the service to the subscriber.
Policy and charging control architectures, such as, but not limited to, the architecture described in 3GPP TS 23.203.
Technical Specification Group Services and System Aspects, Policy and charging control architecture (Release 9) (available on http://www.3gpp.org), integrate the policy and charging control.
Policy and Charging Control (PCC) architecture permits to integrate both policy and charging control, optimizing the information flow. The architecture that supports Policy and Charging Control functionality is shown in FIG. 1 and is in accordance with TS 23.203, which specifies the PCC functionality for Evolved 3GPP Packet Switched domain, including both 3GPP accesses (GERAN/UTRAN/E-UTRAN) and Non-3GPP accesses. In the following, an explanation of the main elements of such architecture will be provided.
The Application Function (AF) is an element offering applications in which service is delivered in a different layer (i.e. transport layer) from the one the service has been requested (i.e. signaling layer), the control of IP bearer resources according to what has been negotiated. One example of an AF is the P-CSCF of the IM CN subsystem. The AF shall communicate with the PCRF (Policy and Charging Rules Function) to transfer dynamic session information (i.e. description of the media to be delivered in the transport layer). This communication is performed using the Rx interface. The information in the Rx interface is derived from the session information in the P-CSCF (e.g. SDP when SIP is used for signalling) and it mainly includes what is called media components. A media component is composed by a set of IP flows, each one described through a 5-tuple, the media type and bandwidth required.
The PCRF (Policy and Charging Rules Function) is a functional element that performs policy control decisions and flow based charging control. The PCRF therefore provides network control regarding the service data flow detection, gating, QoS and flow based charging (except credit management) towards the PCEF (Policy Control Enforcement Function). In particular, the PCRF may include a function that provides policy and charging control for the Media Components negotiated between the user terminal (UE) and the AF. For that purpose, the PCRF creates PCC rules based on the information received from the Rx interface. PCRF, depending on the user and the requested service and/or application, include charging and policy information along with the set of IP filter information: each IP 5-tuple is composed of source and destination IP address and ports, and the protocol id above IP (TCP, UDP). The filters included in PCC rules define what is called Service Data Flows (SDF), i.e. data flows that are treated in the same way regarding policy and charging. This Service Data Flows are installed in PCEF (Policy Control Enforcement Function) through the Gx interface. The Gx reference point is further defined in 3GPP TS 29.212 and lies between the PCRF and the PCEF.
The PCEF (Policy Control Enforcement Function) encompasses service data flow detection based on the filters definitions included in the PCC rules, as well as online and offline charging interactions (not described here) and policy enforcement. The PCEF may further encompass policy enforcement and flow based charging functionalities. Since the PCEF is the one handling the bearers, this is where the QoS is being enforced for the bearer according to the QoS information coming from the PCRF. This functional entity is located at the Gateway (e.g. GGSN in the GPRS case, and PDG in the WLAN case).
Deep packet inspection (DPI) technology, embedded in PCEF, supports packet inspection and service classification, whereby packets, such as IP packets, are classified according to a configured tree of rules so that they are assigned to a particular service session. DPI technology can be also provided in a standalone node, the so/called Traffic Detection Function specified by TS 23.203, as an element of the PCC architecture.
Moreover, DPI technology offers two types of analysis, namely shallow packet inspection and deep packet inspection. Shallow packet inspection extracts basic protocol information, such as IP addresses (source, destination) and other low-level connection states. This extracted information resides in the packet header itself and consequently reveals the principal communication intent. Deep packet inspection, on the other hand, provides application awareness. This is achieved by analysing the content in both the packet header and the payload over a series of packet transactions. There are several possible methods of analysis used to identify and classify applications and/or protocols that are grouped into signatures. One of these methods deals with heuristic signatures which are related to the behavioural analysis of user traffic.
In the PCC architecture, the policy control includes the QoS control. The PCEF enforces the authorized QoS for an IP-CAN bearer according to the information received via the Gx interface and depending on the bearer establishment mode. The IP-CAN (IP Connectivity Access Network) sits between the RAN (Radio Access Network) and the CN (Core Network). Here, the PCC architecture may take decisions according to the type of IP-CAN used. The enforcement of the authorized QoS of the IP-CAN bearer may lead to a downgrading or upgrading of the requested bearer QoS by the PCEF as part of a UE-initiated IP-CAN bearer establishment or modification. Alternatively, the enforcement of the authorised QoS may, depending on operator policy and network capabilities, lead to network initiated IP-CAN bearer establishment or modification. If the PCRF provides authorized QoS for both, the IP-CAN bearer and PCC rule(s), the enforcement of authorized QoS of the individual PCC rules shall take place first.
At IP-CAN session establishment or modification, the PCEF requests the policy rules to the PCRF. In the case that due to the size of the network, several PCRFs are deployed in different sites, the standard defines the DRA functional entity.
The DRA functional entity is defined in the 3GPP standards for PCRF discovery procedures where more than one PCRF is present in an operator's network. It proposes to use Diameter routing procedures using the NAI domain part. This solution assumes that the operator deployment uses one realm per site and that the NAI is used in the network.
Routing of Diameter messages from a network element towards the right Diameter realm in a PLMN is based on standard Diameter realm-based routing, as specified in IETF RFC 3588 using the UE-NAI domain part.
The DRA is defined in 3GPP to support the functionality of a proxy agent and a redirect agent as defined in RFC 3588.
The SPR (Subscriber Profile Register) entity contains all subscriber/subscription related information needed for subscription-based policies and IP-CAN bearer level rules by the PCRF.
Problems with Existing Solutions
User terminals, such as smartphones, tablets and the like, may execute applications and/or use services while being constantly connected to a mobile network. These applications and/or services may apply proprietary protocols or attempt to mimic other well-known protocols. In many occasions, these applications and/or services use encrypted traffic, for example for security reasons. These factors make packet analysis and classification using DPI, for example based on Deep Packet Inspection, not only difficult if not impossible but also very costly from a system resources perspective.
DPI-technologies use heuristic analyzers that detect and identify these protocols based on at least one of heuristic signatures, binary signature patterns, metrics and connectivity patterns. The difficulty of correctly identifying and classifying this type of encrypted traffic means that the application/protocol/service identification accuracy cannot be guaranteed. A higher percentage of encrypted packets therefore leads to lower detection rates.
These DPI techniques therefore facilitate fraud, as traffic may be appropriately encrypted in an attempt to avoid correct analysis and classification of the corresponding service/application/protocol. In addition, this may also obviate the customers charging model.
In addition, many users use tethering to share the internet connection of their mobile phone with their laptops. This avoids paying for separate mobile broadband services or buying additional hardware in order to connect the laptop to the network. From an operator point of view, this is problematic, as users can now use low cost flat rate mobile connections with their home laptops, thus contributing to congestion at the mobile connection interfaces. DPI-techniques designed to detect tethering do not, however, guarantee a 100% detection rate.
In all these cases PCEF network entities apply a heuristic analysis based on heuristic signatures, for example a set of empirical patterns characteristic of a particular protocol or application or service. Each time a user is connected to the network and generates traffic, the PCEF network entity may attempt, based on DPI or the like, to analyze a packet by searching for a possible protocol and hence determining the corresponding application or service.
This additionally creates the following problems:
The number of new protocols and applications and services increases every year. Consequently the current detection protocol mechanisms have to be updated according to the state of the art of the internet protocols in a dynamic way. Therefore, the probability of incorrect protocol detection increases as a consequence of new protocols and applications and services developed every year.
Moreover, a heuristic traffic analyzer applied by the PCEF network entities makes a best guess classification but identification accuracy is not guaranteed to be 100%. This limitation is inherent in the heuristic approach. This type of analysis that keeps track of the behavioral analysis of the packets requires also a highly consuming CPU because more than one packet has to be taken into account for its analysis. Therefore, a heuristic analysis is not suitable from a technical point of view, but also in connection with charging applications.
On the other hand although PCEF network entities from some vendors have a high detection rate for some protocols and applications and services, the number of supported protocols or applications or services is really limited. Internet applications change almost monthly. There are new tendencies, fashions, websites that are changing rapidly. Even the same application or protocols or services are not popular in all countries. For example, many countries have local popular applications (Tencent QQ in China, Windows. Live Messaging in Spain or Skype in Germany) with specific proprietary protocols.
The effort necessary to update these protocols and to collect new popular applications or services is very costly and inefficient. In some cases due to the unbelievable number of existing applications as for example applications downloaded from the Apple Store or Android Market, this makes it almost unfeasible to include them as supported application in any PCEF network entity. Also, it has to be considered that a PCEF network entity is the single point of analysis and/or classification of all services and applications of all users in the core network. Those activities require a high amount of resources, as they consume a high CPU, for example. Moreover, the PCEF network entity has to be interoperable with other elements like a PCRF entity of charging systems so it has become a bottleneck in the overall PCC architecture.
For all these reasons, PCC functions are limited in these applications or services and it cannot be guaranteed that they can correctly be applied for a single user and a specific application or service. The operator has to assume that many PCC functions will apply in best effort or will never be able to be applied. Examples of these applications are Skype, Instant messaging, TV online (Zattoo, Pandora, Slacker), Iphone or android applications, P2P applications (Emule, BitTorrent), SIP, RTSP, online games. Examples of services are VoIP, instant messaging, file transfer and the like.
Operators are also really interested in knowing when users share their Internet connection of an Internet-capable mobile phone with other devices. Tethering is a term responsible of analyzing this technology in which mobile phone is working as a modem. From an analysis perspective, it is very hard with DPI to analyze when subscribers are using tethering.
In summary, currently one of the core of mobile network operators is precisely the privileged access to new Internet tendencies, videos, fashion applications or websites or TV over IP channels. There is therefore an urgent and critical need to improve the bandwidth and access to these services. While the current PCC solution allows to detect, to classify, to improve their QoS, or to also charge the applications, this approach is based on a heuristic analysis that is intrinsically limited and has a low efficiency.
It is therefore desirable to provide improved methods, network entities, system, computer programs and methods to overcome, or at least mitigate the above problems.